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US  space  capabilities  benefit  the  economy,  national  security,  international  relationships,  scientific  discovery,  and 
our  quality  of  life.  Realizing  these  space  responsibilities  is  challenging  not  only  because  the  space  domain  is 
increasingly  congested,  contested,  and  competitive  but  is  further  complicated  by  the  legacy  space  situational 
awareness  (SSA)  systems  approaching  end  of  life  and  inability  to  provide  the  breadth  of  SS A  and  command  and 
control  (C2)  of  space  forces  in  this  challenging  domain.  JMS  will  provide  the  capabilities  to  effectively  employ 
space  forces  in  this  challenging  domain.  Requirements  for  JMS  were  developed  based  on  regular,  on-going 
engagement  with  the  warfighter.  The  use  of  DoD  Architecture  Framework  ( DoDAF )  products  facilitated 
requirements  scoping  and  understanding  and  transferred  directly  to  defining  and  documenting  the  requirements  in 
the  approved  Capability  Development  Document  ( CDD).  As  part  of  the  risk  reduction  efforts,  the  Electronic  System 
Center  (ESC)  JMS  System  Program  Office  (SPO)  fielded  JMS  Capability  Package  (CP)  0  which  includes  an  initial 
sendee  oriented  architecture  (SOA)  and  user  defined  operational  picture  (UDOP)  along  with  force  status,  sensor 
management,  and  analysis  tools.  Development  efforts  are  planned  to  leverage  and  integrate  prototypes  and  other 
research  projects  from  Defense  Advanced  Research  Projects  Agency,  Air  Force  Research  Laboratories,  Space 
Innovation  and  Development  Center,  and  Massachusetts  Institute  of  Technology/Lincoln  Laboratories.  JMS 
provides  a  number  of  benefits  to  the  space  community:  a  reduction  in  operational  “transaction  time”  to  accomplish 
key  activities  and  processes;  ability  to  process  the  increased  volume  of  metric  observations  from  new  sensors  (e.g., 
SBSS,  SST,  Space  Fence),  as  well  as  owner/operator  ephemerides  thus  enhancing  the  high  accuracy  near-real-time 
catalog,  and  greater  automation  of  SSA  data  sharing  supporting  collaboration  with  government,  civil,  commercial, 
and  foreign  entities.  Continued  success  in  JMS  depends  on  continued  support  from  across  the  space  community. 
Key  activities  where  community  participation  is  essential  include  the  C2  SSA  Community  of  Interest  ( COI) 
development  and  refinement,  creative  strategies  for  faster,  better,  cheaper  development,  and  defining  the  next  set  of 
capabilities. 


1.  INTRODUCTION 

US  space  capabilities  benefit  the  economy,  national  security,  international  relationships,  scientific  discovery,  and 
our  quality  of  life.  Recognizing  the  special  importance  of  space  capabilities  to  the  US  military,  the  Commander  of 
United  States  Strategic  Command  (CDRUSSTRATCOM)  designated  Commander,  Joint  Functional  Component 
Command  for  Space  (CDR  JFCC  SPACE)  as  the  single  point  of  contact  for  assigned  military  space  operational 
matters,  to  include  planning,  tasking,  directing,  and  executing  space  operations  [1],  CDR  JFCC  SPACE  conducts 
C2  of  assigned  and  attached  forces  via  the  JSpOC  at  Vandenberg  AFB,  CA. 

Accomplishing  these  Space  responsibilities  is  challenging  not  only  because  the  space  domain  is  increasingly 
congested,  contested,  and  competitive,  but  is  further  complicated  because  the  legacy  systems  supporting  JFCC 
SPACE  are  either  approaching  end  of  life  or  do  not  provide  the  breadth  of  capabilities  necessary  to  provide  the 
space  situational  awareness  (SSA)  and  C2  of  space  forces  in  this  challenging  domain.  The  JMS  was  established  to 
provide  JFCC  SPACE  with  the  capabilities  to  effectively  employ  forces  in  this  challenging  domain. 
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Today,  the  JSpOC  uses  48  separate  systems  and  applications  to  perform  its  mission.  JMS  will  reduce  that  to  39 
systems  and  will  reduce  SSA-specific  systems  and  applications  by  46%. 


2.  REQUIREMENTS 

The  requirements  legacy  for  JMS  is  extensive.  The  space  surveillance  part  of  JMS  has  a  long  history  within 
AFSPC;  space  surveillance  processing  requirements  have  been  continuously  refined  and  honed  over  the  past  40 
years.  Capabilities  for  space  surveillance  and  space  defense  have  been  developed  since  the  mid-1960s.  Systems 
such  as  the  Delta  and  427M  computers  supported  space  surveillance  analysis  from  the  early  1970s.  The  linear 
descent  of  JMS  requirements  starts  with  the  Space  Defense  Operations  Center  (SPADOC)  System  Operational 
Requirements  Document  (SORD)  in  1989  and  results  in  a  highly  refined,  well-understood  set  of  SSA  requirements. 
The  legacy  of  C2  requirements  is  scarcely  less  rich,  being  based  on  the  Air  and  Space  Operations  Center  (AOC)  C2 
construct. 


Requirements  Document 

Effective 

Date 

Key  Components 

Space  Defense  Operations 

Center  (SPADOC)  System 
Operational  Requirements 
Document  (SORD) 

1982 

First  attempt  to  establish  dedicated  stand-alone  SSA  processing 
from  the  Combined  CMC  427M  (Air,  Space,  and  Missile 
processor) 

SPADOC  System  Operational 
Requirements  Document 

1989 

Initial  requirements  for  dedicated  SSA  and  Soviet  threat 
processing  capability.  The  delivered  SPADOC  system  currently 
at  the  JSpOC 

Cheyenne  Mountain  Upgrade 
(CMU)  SORD 

1992 

Initial  requirements  for  upgrading  the  Cheyenne  Mountain 
missile,  air,  and  space  warning  capabilities  -  combined  Integrated 
Threat  Warning/Attack  Assessment  (ITW/AA)  requirements 
combining  air,  missile,  and  space  threat  assessment  and  warning. 

CMU  Operational  Requirements 
Document  (ORD) 

1995 

Transitioning  documentation  for  the  CMU  to  a  newer  format 

NORAD/USSPACECOM 
Warfighter  Support  System 
(NUWSS)  Mission  Need 

Statement  (MNS) 

1998 

High  level  requirements  for  CMU  follow-on  systems  for  missile, 
air,  and  space  warning  and  space  catalog  ITW/AA  capabilities 
for  air,  missile,  and  space  capabilities  refocused  on  a  post-cold 
war  environment 

Space  Control  Capstone 
Requirements  Document  (CRD) 

2000 

Detailed  document  addressing  unique  space  surveillance 
requirements  for  future  follow-on  systems  to  SPADOC 

Space  Surveillance  Reference 
Document  (SSRD) 

2002 

Written  to  develop  and  document  space  surveillance  requirements 
for  the  Space  Control  CRD.  Expected  to  be  a  source  of  detailed 
requirements  for  future  requirements  documents. 

Combatant  Commanders’ 
Integrated  Command  and 

Control  System  (CCIC2S)  ORD 

2004 

Covered  complete  upgrade  to  Cheyenne  Mountain  Operations 
Center  (CMOC)  ITW/AA  capability  -  missile  warning,  air 
warning,  space  catalog,  space  attack  warning  and  command  and 
control 

Joint  C2  Joint  Capabilities 
Document  (JCD) 

2006 

High-level  Joint  Service  document  outlining  the  need  for  Joint  C2 

Space  Control  JCD 

2006 

High-level  documentation  of  evolving  space  control  requirements 
-  SSA  is  addressed  as  a  foundational  requirements  set. 

Space  C2  CDD 

2008 

Requirements  for  C2  of  space  forces,  including  mission-type 
orders  and  a  user-defined  operational  picture.  Met  Air  Force 
Requirements  Oversight  Council  (AFROC)  but  didn’t  proceed  to 
Joint  Requirements  Oversight  Council  (JROC) 

Integrated  Space  Situational 
Awareness  (ISSA)  Capability 

2008 

Described  system  that  would  deliver  a  highly  accurate  space 
object  catalog,  space  event  analysis  tools,  space  intelligence  and 

Requirements  Document 

Effective 

Date 

Key  Components 

Description  Document  (CDD) 

environment  effects  assessment  tools,  and  threat  warning 
capabilities.  Did  not  go  to  AFROC. 

Rapid  Attack,  Identification, 
Detection,  and  Reporting 

System.  (RAIDRS)  Block  20 

CDD 

2008 

First  attempt  to  derive  possible  space  threats  from  non-SSA 
sources.  This  CDD  only  completed  the  initial  review  by  a  Pre- 
High  Performance  Team,  (HPT)  when  funding  was  withdrawn 
from  the  project  and  the  threat  processing  for  threat  identification 
and  notification  requirements  were  consolidated  in  the  JMS  CDD 

JMS  CDD 

2010 

Incorporated  all  major  elements  of  the  Space  C2,  ISSA  and  the 
RB20  CDDs  requirements 

JMS  Functional  Requirements 
Document  (FRD) 

2011 

A  focused  set  of  operational  requirements  extracted  from  the  JMS 
CDD.  Expedites  replacing  current  legacy  space  surveillance 
processing  capabilities  and  delivering  initial  C2  functions.  Not  a 
JCIDS  document. 

Table  1.  History  of  Space  Surveillance,  C2,  and  SSA  Requirements  Documents 


There  has  been  significant  user  involvement  in  generating  the  requirements  documents  shown  in  Table  1  above.  For 
example,  requirements  for  the  NUWSS  MNS  and  the  CCIC2S  ORD  were  based  on  a  business  process  reengineering 
activity  which  included  an  entire  CMOC  operations  crew  for  a  year  defining  current  operations  processes  and 
identifying  needed  system  improvements  to  keep  pace  with  changing  operational  environments.  Development  of  the 
Space  C2,  ISSA,  and  JMS  CDDs  involved  a  wide  variety  of  SSA  stakeholders  across  the  Services,  both  producers 
and  consumers.  The  SSA  requirements  in  particular  required  wide  review  and  discussion  due  to  the  broad  and 
diverse  nature  of  both  producers  and  consumers  -  from  traditional  AFSPC  customers  to  other  Services,  NASA,  and 
other  US  Government  agencies. 

Another  key  facet  of  SSA  and  Space  C2  requirements  development  is  the  long-standing  and  extensive  use  of 
architectural  models.  Starting  with  the  CCIC2S  program  and  continuing  through  Space  C2,  ISSA,  and  ending  up 
with  JMS,  DoD  Architecture  Framework  (DoDAF)  products  facilitated  requirements  scoping  and  understanding  and 
transferred  directly  to  defining  and  documenting  the  requirements  in  the  CDD. 

The  current  JMS  Enterprise  Architecture  (EA)  provides  elaboration  of  the  capabilities  defined  in  the  JMS  CDD. 
These  include  C2  of  space  forces,  generation  of  actionable  information  about  the  space  situation,  and  warning  of 
threats  against  space  systems.  The  JMS  EA  presents  the  vision  for  net -centric  system  services  and  provides  JMS 
stakeholders  the  means  to  trace  from  “CONOPS-to-code”  in  managing  the  development  of  the  integrated  solution. 
It  is  the  primary  vehicle  for  communicating  requirements  to  the  development  team  and  will  aid  in  the  design, 
development,  testing,  and  training  activities  associated  with  fielding  and  operating  JMS  as  capabilities  are 
incrementally  deployed.  It  will  be  continually  refined  and  updated  as  system  implementation  unfolds. 

A  crucial  piece  of  the  JMS  requirements  process  has  been  the  use  of  the  Information  Technology  (IT)  Box 
requirements  approach,  illustrated  in  Fig  1.  The  IT  Box  was  added  to  the  Joint  Capabilities  Integration  and 
Development  System  (JCIDS)  to  give  IT  programs  the  flexibility  and  planning  to  incorporate  evolving  technologies 
throughout  a  programs  life  cycle  [3],  Importantly,  this  gives  programs  the  authority  to  evolve  requirements  beyond 
initial  minimum  values.  Using  the  IT  Box  approach  will  allow  us  to  include  as  much  capability  in  the  initial 
increment  as  possible  given  the  programmed  resources.  JMS  will  continue  to  evolve  through  future  increments 
expanding  the  number  of  service  and  applications  to  address  future  requirements. 


Key  Performance  Parameters 

•  KPP  #1  -  UDOP 

•  Display  interactive,  user  definable, 
decision  and/or  situational 
awareness  quality,  actionable, 
layered  information  about 
operational  environment 

•  KPP  #2  -  Provide  Authoritative  Data 
Source  of  High  Accuracy  Space  Object 
Positional  Information 

•  Perform  high-accuracy  trajectory/ 
orbit  determination  for  all  identified 
RSOs  in  space  and  in  Earth 

•  KPP  #3  -  Predict  &  Report  Orbital 
Conjunctions 

•  Identify  and  report  orbital 
conjunctions  of  user-specified 
systems  from  pre-launch  screening 
through  end  of  life  operations. 

•  KPP  #4  -  Operational  Availability 

•  KPP  #5  -  Net-Ready 

•  Net-ready  KPP  compliance 
(architecture,  data  standards,  IA, 
tech  standards  and  interfaces,  and 
suppo  liability) 


Organization  &  Direction 

Flag-level  oversight  thru  JMS 
Requirements  &  Planning  Council  (R&PC) 

•  Co-Chairs 

•  CDR  JFCC-SPACE,  PEO/C2&CS 

•  Senior  Council 

•  PEO/Space,  HQ  AFSPC/A5 

•  Members 

•  HQ  USSTRATCOM,  HQ  AFSPC,  JFCC 
SPACE,  SMDC/ARSTRAT,  NRO,  NGA,  ESC, 
SMC,  NAVNETWARCOM,  NASA,  1C,  14  AF, 
24  AF,  CFE,  others  as  appropriate 


JSpOC  Mission 

System 

JMS 

R&PC  Responsibilities: 

•  Prioritize  and  allocate 
requirements 

•  Monitor  Operational 
capability 

development/fielding 

•  Identify  out-of-cycle 
requirements  for  execution 


Application  &  System  Software 

Development  Cost 


JROC  approved, 10  Dec  10:  JROCM  189-10 


Fig.  1.  The  JMS  IT  Box 


The  purpose  of  the  “IT  Box”  is  to  describe  and  visualize  the  overall  bounds  of  an  IT  program  in  order  to  facilitate 
program  initiation,  as  well  as  to  reduce  subsequent  return  trips  to  the  JROC  for  approval  of  improved  capabilities  as 
the  program  is  executed.  The  information  in  the  chart  was  provided  to  the  Joint  Capabilities  Board  (JCB)  and  the 
JROC  as  part  of  the  approval  process  for  the  JMS  CDD. 

Using  an  IT  Box  approach  to  requirements  statement  and  approval  has  become  a  useful  part  of  the  JMS 
requirements  process  as  the  development  and  acquisition  process  continues  to  evolve.  Due  to  the  operational 
urgency  in  deploying  JMS,  the  acquisition  approach  has  had  to  become  more  responsive.  The  movement  towards 
more  use  of  existing  prototypes  and  projects  has  forced  AFSPC  to  reconsider  the  immediate  emphasis  in 
development  and  delivery;  that  is,  the  Command  has  had  to  examine  its  requirements  and  determine  what  can  be 
delivered  sooner  based  on  existing  prototype  work. 


3.  WHERE  WE  ARE  NOW 

The  JMS  CDD  was  approved  by  the  JROC  in  December  2010  [2],  capping  a  multi-year,  multi -document  effort.  The 
requirements  in  the  CDD  were  vetted  in  two  stages  -  once  during  development  of  the  predecessor  Space  C2,  ISSA, 
and  RB  20  CDDs  and  again  for  the  JMS  CDD  review  and  approval  process.  The  Space  C2  CDD  was  moved 
through  the  Joint  Capabilities  Integration  and  Development  System  (JCIDS)  process  to  the  AFROC  and  was 
approved  in  2008.  The  ISSA  CDD  was  ready  for  the  AFROC  but  was  stopped  due  to  programmatic  decisions  that 
combined  Space  C2,  ISSA,  and  RB  20  into  the  JMS  program.  The  RB  20  CDD  was  on  a  later  schedule  and  didn’t 
leave  AFSPC  for  the  same  reason.  However,  the  requirements  were  reviewed  extensively  both  through  an  initial 
process  that  involved  producers  and  consumers  and  (for  Space  C2  and  ISSA)  the  formal  JCIDS  coordination  process 
prior  to  reaching  the  AFROC.  The  JMS  CDD  completed  the  entire  JCIDS  process  as  it  progressed  to  the  JROC  and 
approval. 

The  JMS  acquisition  approach  has  been  modified  to  focus  near-term  efforts  on  replacing  the  current  space 
surveillance  processing  system  (SPADOC)  and  its  supporting  Astrodynamic  Support  Workstation  (ASW).  To  meet 
this  priority,  the  immediate  focus  of  development  efforts  is  to  leverage  and  integrate  prototypes  and  other  research 
projects  from  the  Defense  Advanced  Research  Projects  Agency,  Air  Force  Research  Laboratories,  Space  Innovation 


and  Development  Center,  and  Massachusetts  Institute  of  Technology/Lincoln  Laboratories.  To  support  this  effort, 
HQ  AFSPC  produced  a  Functional  Requirements  Document  (FRD),  a  subset  of  CDD  requirements  focused  on  the 
initial  space  surveillance  processing  need.  The  remaining  JMS  CDD  requirements  will  be  satisfied  in  later 
development  releases.  No  new  requirements  documents  will  be  needed. 


In  the  meantime,  JMS  Capability  Package  (CP)  0  is  now  operational.  CP  0’s  purpose  is  to  develop  a  net-centric 
SOA  infrastructure  deployed  to  the  GIG  and  provide  initial  infrastructure  for  future  JMS  capabilities.  Some  initial 
capabilities  have  been  deployed  within  CP  0: 


Architecture  and  Infrastructure 

Data  Consumed  by  JMS  with 
Sources 

Data  Exposed  by  JMS  CP  0 

•  Common  modular  infrastructure 

•  Source:  COLT 

•  Sensor  maintenance  schedule 

and  core  services 

•  Sensor  Maintenance  schedules 

(COLT) 

•  Security,  messaging,  data 

•  Source:  Single  Integrated  Space 

•  JMS  developed  web  service 

management,  enriched 

Picture  (SISP) 

•  Event  and  sensor  availability 

collaboration,  etc 

•  Element  Set  Data 

correlation  (JMS) 

•  Commercial  off-the-shelf 
(COTS)-based  middleware  & 

•  Satellite  system  data 

•  Observation  Schedule 

Net-Centric  Enterprise 

•  Space  Order  of  Battle 

•  Pass  Schedule 

Services 

•  Source:  Defense  Intelligence 

•  High  interest  event  data  (nJET) 

•  Integrated,  tailorable  user 

Space  Order  of  Battle  (DISOB) 

•  JMS  developed  web  service 

workspaces 

•  Uncooperative  launch 

•  Cooperative  launch  information 

•  Space  User  Defined  Operating 

schedules 

(SPADOC) 

Picture  (UDOP) 

•  Red/Grey  on-orbit  asset  status 

•  UDOP  document  (JMS) 

•  Mission  service  development  & 

•  Source:  Modernized  Intelligence 

•  JSpOC  Crew  Log  (JMS) 

integration  focused  on  AFSPC 

Database  (MIDB) 

•  Sensor  characteristics  (SPADOC, 

mission  threads 

•  Red/Grey  ground  target  data 

SISP) 

•  Force  status  and  Sensor 

•  Source:  Space  Intelligence 

•  Object  owner/operator 

management 

Preparation  of  the  Battlespace 

information  (SIPB) 

(SIPB) 

•  Analytical  Services  (Web  ISSA) 

•  Country  owner  operator 

•  Conjunction  Assessment, 

information 

Direct  Ascent  ASAT,  Direct 

•  Source:  SKIWEB 

Energy,  Overfly 

•  Events 

•  Space  Environmental  Effects 

•  Blog  entries 

(SEEFS) 

•  Source:  SPADOC 

•  Cooperative  launch  data 

•  T3  message 

•  Source:  nJET 

•  Breakups 

•  Confirmed  maneuvers 

•  Conjunctions 

•  Reentries 

•  SSN  sensor  data 

•  NTM  mission  data  (BVI) 

Table  2.  CP  0  Content 


4.  BENEFITS  TO  THE  SPACE  COMMUNITY 


JMS  provides  a  number  of  benefits  to  the  space  community.  Many  of  them  are  due  to  the  use  of  modern  software 
techniques,  to  include  use  of  a  service  oriented  architecture.  Others  stem  from  the  use  of  modern  hardware  that 
enable  high  speed,  high  volume  processing. 

First,  JMS  capabilities  will  reduce  the  operational  “transaction  time”  to  accomplish  key  activities  and  processes.  For 
example,  JMS  will  have  the  capacity  to  perform  40,000  uncorrelated  target  (UCT)  observations  associations  per  day. 
This  performance  is  necessary  due  to  the  greatly  increased  numbers  of  UCTs  expected  from  new  sensors  such  as  the 
Space-Based  Surveillance  System  (SBSS)  and  Space  Fence.  JMS  will  need  to  correlate  these  UCTs  with  cataloged 
RSOs  quickly  so  as  to  be  able  to  process  further  UCTs.  Performance  enhancements  like  these  cascade  through  other 
capabilities,  such  as  conjunction  assessment  screening.  Currently,  CA  updates  for  each  RSO  as  run  as  part  of  a  shift 
update  in  an  all-active-on-all  screening.  The  run  takes  between  six  and  eight  hours,  which  limits  the  amount  of  time 
the  crew  on  shift  has  to  perform  any  analysis  they  are  tasked  for.  In  contrast,  JMS  is  required  to  perform  a  “one -on- 
many  CA”  every  time  an  RSO’s  state  vector  is  updated.  Launch  processing  during  flyout  is  similarly  improved. 


Second,  JMS  will  process  the  increased  volume  of  metric  observations  from  new  sensors  (e.g.,  SBSS,  SST,  Space 
Fence)  as  well  as  owner/operator  ephemerides.  Table  3  shows  the  expected  production  of  observations  from  the 
new  sensors. 


Sensor 

Number  of  Observations  per  Day 

Space  Fence 

750,000  per  site  X  2  sites  planned  =  1,500,000 

Space  Surveillance  Telescope  (SST) 

21,600 

Space-Based  Surveillance  system  (SBSS) 

14,000 

Table  3.  Observation  Throughput  From  New  Space  Surveillance  Sensors 


The  current  SPADOC  system  has  demonstrated  the  ability  to  process  up  to  710,000  observations  per  day  with  a 
20,500  RSO  catalog  [5];  beyond  this  level,  performance  dropped  significantly  due  to  SPADOC’s  throughput 
limitations.  The  expected  Space  Fence  loading  from  one  site  will  exceed  this  current  maximum.  Note  that,  during 
the  test  period,  the  average  throughput  was  410,500  observations  per  day  during  routine  operations  [5],  Today’s 
catalog  is  now  almost  18,000  RSOs  larger  with  a  consequent  increase  in  the  number  of  observations  in  the  SPADOC 
system.  Comparing  just  the  Space  Fence  obs  production  number  to  the  high-load  test  capacity  in  Ref  5,  it’s  clear 
that  the  SPADOC  system  won’t  be  able  to  ingest  all  those  observations.  JMS  addresses  this  deficiency. 

Finally,  it  provides  greater  automation  of  SSA  data  sharing  with  government,  civil,  commercial,  and  foreign  entities. 
The  emergence  of  SSA  data  sharing  and,  more  recently,  the  Combined  Space  Operations  Center  (CSpOC)  concept, 
has  increased  the  importance  of  providing  SSA  data  to  a  much  wider  user  community  crucial.  The  CSpOC  is 
intended  to  leverage  existing  alliances  to  provide  for  common  defense  and  safety  of  space  assets  and  shared 
command  and  control.  SSA  data  sharing  is  an  integral  part  of  combines  space  operations  and  automating  this  and 
other  shared  capabilities  is  fundamental  to  enabling  shared  SSA  and  C2  with  our  Allies  and  partners. 


5.  WHAT  WE  NEED 

To  build  on  the  success  of  CP  0,  we  need  continued  support  from  across  the  space  community.  Key  activities  where 
community  participation  is  essential  includes  C2  SSA  Community  of  Interest  development  and  refinement;  creative 
strategies  for  faster,  better,  and  cheaper  development;  and  defining  the  next  set  of  capabilities. 

Gen  James  Cartwright,  the  Vice-Chairman  of  the  Joint  Chiefs  of  Staff  (VCJCS)  recently  set  four  challenges  for  the 
JMS  program.  These  challenges  go  beyond  simply  replacing  the  current  legacy  JSpOC  systems,  such  as  SPADOC 
and  CAVENet;  they  challenge  the  traditional  view  of  consuming,  processing  and  distributing  a  limited  set  of  space 
data  for  a  limited  audience.  They  are: 


-  Develop  the  Combined  Space  Operations  Center  (CSpOC)  using  JMS  as  the  core  processing  capability. 

This  challenge  is  intended  to  make  sharing  operational  C2  of  space  forces  with  Allies  a  workable  proposition. 

It  includes  accepting  data  from  a  wide  variety  of  sources,  processing  it  in  an  environment  that  allows  maximum 
foreign  participation,  and  providing  a  wide  variety  of  SSA  and  C2  products  to  an  international  audience. 
Discussions  with  USSTRATCOM,  JFCC  SPACE,  and  14  AF  indicate  that  the  key  data  handling,  processing, 
and  distribution  considerations  are  addressed  by  JMS.  For  example,  the  JMS  CDD  contains  all  relevant 
requirements  to  enable  Combined  operations  using  JMS  such  as  orbit  determination,  SSA  event  processing,  and 
data  handling  security.  The  fundamental  cross-domain  security  requirements  have  been  extensively  vetted  by 
the  SSA  and  JMS  development  community  and  are  explicitly  listed  in  the  CDD 

-  Improve  data  integration,  especially  with  ISR,  missile  warning,  missile  defense  data 

This  is  one  of  the  key  rationales  for  JMS  -  better,  faster,  broader  data  integration  with  a  wider  variety  of  data 
sources.  In  contrast  to  SPADOC,  JMS  is  expected  to  not  only  be  able  to  accept  and  integrate  traditional  SSN 
tracking  data  -  including  data  from  US  missile  warning  radars  -  but  also  non-traditional  formatted  observations 
and  ephemerides  from  a  variety  of  sources,  positional  data  derived  from  satellite  telemetry,  and  tracking  data 
from  foreign  sensors.  In  many  cases,  the  data  will  be  delivered  net-centrically  using  the  Net-Centric  Sensors 
and  Data  Sources  (N-CSDS)  capability. 

-  Use  of  and  interaction  with  foreign  data  providers 

The  CSpOC  concept  mentioned  above  also  requires  that  the  CSpOC’s  space  surveillance  processing  system  - 
JMS  -  be  able  to  accept  space  surveillance  data  from  foreign  sensors  and  data  sources.  Designing  JMS  to  meet 
the  data  integration  challenge  and  instantiating  effective  cross  domain  solutions  to  protect  data  are  key  to 
meeting  this  challenge. 

-  Attain  IT  efficiencies 

The  current  JSpOC  capabilities  are,  in  general,  performed  by  IT  systems  that  are  several  generations  old. 

Current  IT  architectures  will  inherently  provide  significant  IT  efficiencies.  Massively  parallel  and  service- 
oriented  architectures,  modern  programming  languages,  and  modern  hardware  will  all  contribute  to  improving 
computational  performance.  DOD  guidance  requiring  the  use  of  the  Defense  Enterprise  Computing  Centers 
(DECC)  cloud  computing  architecture  will  force  use  of  state-of-practice  systems  and  capabilities.  The  JMS 
CDD  also  forces  use  of  modern  IT  due  to  performance  criteria  levied  in  the  requirements.  For  example,  look  at 
the  performance  requirement  for  conjunction  assessment: 

The  system  shall  screen  a  RSO  following  a  state  vector  update,  or  at  least  every  24  hours, 
forecasting  a  five-day  conjunction  screening.  The  system  shall  screen  a  space  catalog  of  100,000 
RSOs,  or  current  catalog  size  (whichever  is  greater),  in  less  than  three  hours. 

Screening  a  100.000RSO  catalog  within  three  hours  means  several  hundred  million  orbit  comparisons 
in  that  time.  This  requirement  forces  use  of  massively  parallel  processing  and  high-speed  input/output. 

There  are  other  areas  where  modern  IT  will  be  needed.  A  key  area  and  one  related  to  the  CSpOC 
challenge  above,  is  attribute-based  access  control  (ABAC).  This  modern  approach  to  personnel  access 
to  JMS  will  enable  appropriate  access  by  CSpOC  operators  based  on  their  national  policies  and 
agreements. 

6.  CONCLUSION 

JFCC  SPACE  needs  a  modern  capability  to  command  and  control  her  assigned  and  attached  space  forces.  Air  Force 
Space  Command  has  produced  the  JSpOC  Mission  System  as  the  solution  to  the  need.  JMS  has  a  long  requirements 
pedigree  -  the  need  has  been  clear  and  consistent  for  over  30  years.  As  JFCC  SPACE’S  responsibilities  grow  and 
transform  the  JSpOC  into  the  CSpOC,  the  need  for  a  modern,  fully  automated  data  processing  solution  becomes 
more  and  more  obvious.  JMS  is  starting  to  field  a  solution  that  already  improves  JSpOC  crewmembers’  operations 
today  and  lays  the  foundation  for  more  improvements  in  the  near  term  and  for  broader,  further -reaching  space  C2 
and  SSA  capabilities  in  the  future.  JMS  will  be  a  key  contributor  to  mastering  the  increasingly  congested,  contested, 
and  competitive  space  domain. 
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ACRONYM  LIST 


AFROC 

Air  Force  Requirements  Oversight  Council 

AOC 

Air  and  Space  Operations  Center 

ASW 

Astrodynamic  Support  Workstation 

BVI 

Battlespace  Visualization  Initiative 

C2 

Command  and  Control 

CDD 

Capability  Development  Document 

COI 

Community  of  Interest 

COLT 

Combat  Capability  Assessment  Schedule  (CCAS)  On-Line  Tool 

COTS 

Commercial  Off-The-Shelf 

DoDAF 

DoD  Architecture  Framework 

EA 

Enterprise  Architecture 

GOTS 

Government  Off-The-Shelf 

ISSA 

Integrated  Space  Situational  Awareness 

JFCC  SPACE 

Joint  Functional  Component  Commander  for  Space 

JMS 

JSpOC  Mission  System 

JROC 

Joint  Requirements  Oversight  Council 

JSpOC 

Joint  Space  Operations  Center 

ORD 

Operational  Requirements  Document 

RAIDRS 

Rapid  Attack,  Identification,  Detection,  and  Reporting  System. 

SEEFS 

SSA  Environmental  Effects  Fusion  System 

SISP 

Single  Integrated  Space  Picture 

SOA 

Service  Oriented  Architecture 

SORD 

System  Operational  Requirements  Document 

SPADOC 

Space  Defense  Operations  Center 

SPO 

System  Program  Office 

SSA 

Space  Situational  Awareness 

UDOP 

User-Defined  Operational  Picture 

CMOC 

Cheyenne  Mountain  Operations  Center 

FRD 

Functional  Requirements  Document 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

UCT 

Uncorrelated  Tracks 

RSO 

Resident  Space  Object 

CSpOC 

Combined  Space  Operations  Center 

